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ABSTRACT 



Methods and apparatus for a smartcard system are provided 
which securely and conveniently integrate important travel- 
related applications. In one embodiment, a smartcard system 
includes a cardholder identification application and various 
additional applications useful in particular travel contexts; 
for example, airline, hotel, rental car, and payment-related 
applications. Furthermore, memory space and security fea- 
tures within specific applications provide partnering orga- 
nizations (e.g., airlines, hotel chains, and rental car agencies) 
the ability to construct custom and secure file structures. 

14 Claims, 9 Drawing Sheets 
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METHODS AND APPARATUS FOR A 
TRAVEL-RELATED MULTI FUNCTION 
SMARTCARD 

TECHNICAL FIELD 5 

The present invention relates generally to the use of 
integrated circuit cards, or "smartcards," for commercial 
transactions and, more particularly, to methods and appara- 
tus for conveniently storing, retrieving, and updating data 
related to a cardholder's travel information in the context of 10 
a distributed transaction system, 

BACKGROUND ART AND TECHNICAL 
PROBLEMS 

Despite advances in information technology and process 15 
streamlining with respect to travel arrangements, the modem 
traveler is often subjected to unnecessary delays, petty 
inconveniences, and oppressive paperwork. These travel 
burdens are most evident in the airline, hotel, and rental car 2Q 
industries, where arranging and paying for services and 
accommodations can involve significant time delays due to 
miscommunication, poor record-keeping, and a host of other 
administrative inefficiencies. 

Smartcard technology, as described below, has had lira- 2 s 
ited success in addressing some of these problems. The term 
"smartcard" refers generally to wallet-sized or smaller cards 
incorporating a microprocessor or microcontroller to store 
and manage data within the card. More complex than 
magnetic-stripe and stored-value cards, smartcards are char- 30 
acterized by sophisticated memory management and secu- 
rity features. A typical smartcard includes a microcontroller 
embedded within the card plastic which is electrically con- 
nected to an array of external contacts provided on the card 
exterior. A smartcard microcontroller generally includes an 35 
electrically-erasable and programmable read only memory 
(EEPROM) for storing user data, random access memory 
(RAM) for scratch storage, and read only memory (ROM) 
for storing the card operating system. Relatively simple 
microcontrollers are adequate to control these functions. 4Q 
Thus, it is not unusual for smartcards to utilize 8-bit, 5 MHZ 
microcontrollers with about 8K of EEPROM memory (for 
example, the Motorola 6805 or Intel 8051 microcontrollers). 

A number of standards have been developed to address 
general aspects of integrated circuit cards, e.g.: ISO 7816-1, 45 
Part 1. Physical characteristics (1987); ISO 7816-2, Part 2: 
Dimensions and location of the contacts (1988); ISO 7816- 
3, Part 3: Electronic signals and transmission protocols 
(1989, Amd. 1 1992, Amd. 2 1994); ISO 7816-4, Part 4; 
Inter-industry commands for interchange (1995); ISO 7816- 50 
5, Part 5: Numbering system and registration procedure for 
application identifiers (1994, Amd. 1 1995); ISO/IEC DIS 
7816-6, Interindustry data elements (1995); ISO/IEC WD 
7816-7, Part 1: Enhanced interindustry commands (1995); 
and ISO/IEC WD 7816-8, Part 8: Inter-industry security 55 
architecture (1995). These standards are hereby incorpo- 
rated by reference. Furthermore, general information regard- 
ing magnetic stripe cards and chip cards can be found in a 
number of standard texts, e.g., Zoreda & Oton, SMART 
CARDS(1994), and Rankl & Effing, SMARTCARDS HAND- 60 
BOOK (1997), the contents of which are hereby incorpo- 
rated by reference. 

Various attempts have been made to alleviate travel- 
related inconveniences through the use of smartcard tech- 
nology. In 1995, for example, the U.S. airline industry led an 65 
effort to reduce ticket distribution costs by developing 
standards for "ticketless travel. "Soon thereafter, a joint 



2 

conference of IAEA and ATA adopted a set of specifications 
entitled Specifications for Airline Industry Integrated Circuit 
Cards (hereinafter, "LATA standard"). Similarly, in the field 
of financial payment systems, a standard has been developed 
entitled EMV Version 2.0, Integrated Circuit Card Specifi- 
cationsfor Payment Systems, Parts 1-3 (1995). Both of these 
specifications are hereby incorporated by reference. 

Notwithstanding widespread promulgation of these 
standards, smartcard efforts tend to remain fragmented, and 
the resultant benefit to consume is — particularly consumers 
who travel — has been quite minimal. One recent study 
estimates that approximately nine million smartcards were 
issued in the transportation and travel industry in 1996, yet, 
for the most part, these cards remain incompatible; that is, 
due to differing file structures and/or communication proto- 
cols employed, card data typically can not easily be shared 
across applications or between industry participants. 

Systems and methods are therefore needed in order to 
overcome these and other shortcomings in the prior art. 

SUMMARY OF THE INVENTION 

The present invention provides methods and apparatus for 
a smartcard system which securely and conveniently inte- 
grates important travel-related applications, thereby over- 
coming the limitations of the prior art. In accordance with 
one aspect of the present invention, a smartcard system 
comprises a cardholder identification application and vari- 
ous additional applications useful in particular travel con- 
texts; for example, airline, hotel, rental car, and payment- 
related applications. In accordance with another aspect of 
the present invention, a smartcard system further comprises 
space and security features within specific applications 
which provide partnering organizations the ability to con- 
struct custom and secure file structures. 

BRIEF DESCRIPTION OF THE DRAWING 
FIGURES 

The present invention will hereinafter be described in 
conjuction with the appended drawing figures, wherein like 
numerals denote like elements, and: 

FIG. 1 illustrates an exemplary smartcard apparatus; 

FIG. 2 is a schematic diagram of an exemplary smartcard 
integrated circuit, showing various functional blocks; 

FIG. 3 is an examplary diagram of files and directories 
arranged in a typical tree structure; 

FIG. 4 sets forth an exemplary database structure in 
accordance with a preferred embodiment of the present 
invention; 

FIG. 5 sets forth a preferred cardholder ID data structure 
in accordance with the present invention; 

FIG. 6 sets forth a preferred payment system data struc- 
ture in accordance with the present invention; 

FIG. 7 sets forth a preferred airline data structure in 
accordance with the present invention; 

FIG. S sets forth a preferred rental car data structure in 
accordance with the present invention; 

FIG. 9 sets forth a preferred hotel system data structure in 
accordance with the present invention; and 

FIG. 10 illustrates an exemplary distributed transaction 
system useful in practicing the present invention. 

DETAILED DESCRIPTION OF PREFERRED 
EXEMPLARY EMBODIMENTS 

Referring now to FIGS. 1 and 2, an exemplary smartcard 
system suitable for practicing the present invention will now 
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be described. A smarlcafa-IOO-generally--comprises"a _ card Only Memory (ROM) 214, Central Processing Unit (CPU) 
body 102 having a communication region 104 for providing 202, data bus 210, Input/Output (I/O) 208 and Electrically- 
contact or non-contact communication between an external Erasable and Programmable Read Only Memory 
device (e.g., a card reader) and an integrated circuit 110 (EEPROM) 212. 

encapsulated within card body 102. Communication region 5 RAM 216 comprises volatile memory which is used by 
104 preferably comprises six conductive pads 106 whose the card primarily for scratch memory, e.g., to store inter- 
placement and size conform to IS07816-2. More mediate calculation results and data encryption processes, 
particularly, a communication region 104 in conformance RAM 216 preferably comprises at least 256 bytes, 
with ISO-7816-2preferably comprises VCC contact 106(a) EEPROM 212 provides a non-volatile memory region 
(power supply), RST contact 106(6) (reset), CLK contact 1Q which is erasable and rewritable electrically, and which is 
106(c) (external clock), GND Contact 106(d) (ground), VPP used to store, inter alia, user data, system data and applica- 
contact 106(e) (programming voltage), and I/O contact tion files. In the context of the present invention, EEPROM 
106(f) (data line). 212 is suitably used to store a plurality of files related to 
VCC 106(a) suitably provides power to IC 110 (typically cardholder travel information (discussed in greater detail 
5.0 V +/-10%). CLK 106(c) is suitably used to provide an 15 below in conjunction with FIG. 3). EEPROM 212 preferably 
external clock source which acts as a data transmission comprises at least 8K bytes. 

reference. RST 106(6) is suitably used to transmit a reset In a preferred embodiment, CPU 202 implements the 

signal to IC 110 during the booting sequence. VPP contact instruction set stored in ROM 202, handles memory man- 

106(e) may be used for programming of EEPROM 212 in IC agement (i.e., RAM 216 and EEPROM 212), and coordi- 

110. As is known in the art, however, this contact is 20 nates input/output activities (i.e., I/O 208). 

generally not used since modern ICs typically incorporate a ROM 214 preferably contains, or is "masked" with, the 

charge pump suitable for EEPROM programming which smart card operating system (SCOS). That is, the SCOS is 

takes its power from the supply voltage (VCC 106(a)). 1/0 preferably implemented as hard-wired logic in ROM 214 

106(f) suitably provides a line for serial data communication using standard mask design and semiconductor processing 

with an external device, and GND 106(d) is suitably used to 25 methods well known in the art (e.g., photolithography, 

provide a ground reference. Encapsulated integrated circuit diffusion, oxidation, ion implantation, etc.). Accordingly, 

110 is configured to communicate electrically with contacts ROM 214 cannot generally be altered after fabrication. The 

106 via any number of known packaging techniques, purpose of such an implementation is to take advantage of 

including, for example, thermosonically -bonded gold wires, the fast access times provided by masked ROMs. ROM 214 

tape automated bonding (TAB), and the like. 30 suitably comprises about 4K-20K bytes of memory, pref- 

While an exemplary smartcard is discussed above in the erably at least 16K bytes. In this regard, it will be appreci- 

context of a plurality of external contacts, it will be appre- ated that alternate memory devices may be used in place of 

ciated that contactle ss-cards-may ^also be utilized to practice ROM 214. Indeed, as semiconductor technology progresses, 

this inventioriTTrlaTis, non-contact communication methods it may be advantageous to employ more compact forms of 

may be employed using such techniques as capacitive 35 memory, for example, flash-EEPROMs. 

coupling, inductive coupling, and the like. As is known in The SCOS controls information flow to and from the card, 

the art, capacitive coupling involves incorporating capaci- and more particularly facilitates storage and retrieval of data 

tive plates into the card body such that data transfer with a stored within EEPROM 212. As with any operating system, 

card reader is provided through symmetric pairs of coupled the SCOS operates according to a well-defined command 

surfaces, wherein capacitance values are typically 10-50 40 set. In this regard, a variety of known smart card operating 

picofarads, and the working range is typically less than one systems are suitable for the purpose of this invention, for 

millimeter. Inductive coupling employs coupling elements, example, IBM's Multi-Function Card (MFC) Operating 

or conductive loops, disposed in a weakly-coupled trans- System 3.51, the specification of which is hereby incorpo- 

former configuration employing phase, frequency, or ampli- rated by reference. While the IBM MFC operating system 

tude modulation. In this regard, it will be appreciated that the 45 employs the standard tree structure of files and directories 

location of communication region 104 disposed on or within substantially in accordance with IS07816-4 (as detailed 

card 100 may vary depending on card configuration. For below), it will be appreciated by those skilled in the art that 

additional information regarding non-contact techniques, other operating system models would be equally suitable for 

see, for example, contactless card standards ISO/IEC 10536 implementation of the present invention. Moreover, it may 

and ISO/IEC 14443, which are hereby incorporated by 50 be advantageous to allow certain aspects of operating system 

reference. functionality to exist outside the card, i.e., in the form of 

Smartcard body 102 is preferably manufactured from a blocks of executable code which can be downloaded and 

sufficiently rigid material which is resistant to various envi- executed by the smartcard during a transaction (for example, 

ronmental factors, e.g., physical deterioration, thermal Java applets, ActiveX objects, and the like), 

extremes, and ESD (electrostatic discharge). Materials suit- 55 Given the general characteristics of smartcard 100 as 

able in the context of the present invention include, for outlined above, it will be apparent that a wide range of 

example, PVC (polyvinyl chloride), ABS (acrylonitrile- microcontrollers and contact-based smartcard products 

butadiene-styrol), PET (polyethylene terephthalate), or the known in the art may be used to implement various embodi- 

like. In a preferred embodiment, chip card 100 conforms to ments of the present invention. Suitable smartcards include, 

the mechanical requirements set forth in ISO 7810, 7813, 60 for example, the model ST16SF48 card, manufactured by 

and 7816. Body 102 may comprise a variety of shapes, for SGS-Thomson Microelectronics, which incorporates a 

example, the rectangular ID-l,ID-00, or ID-000 dimensions Motorola 6805 microcontroller with 16K ROM, 8K 

set forth in IS 0-78 10. In a preferred embodiment, body 102 EEPROM, and 384 bytes of RAM. It will be appreciated, 

is roughly the size and shape of a common credit card and however, that particular embodiments of the present inven- 

substantially conforms to the ID-1 specification. 55 tion might require more advanced microcontrollers with 

Referring now to FIG. 2, IC 110 preferably comprises greater EEPROM capacity (i.e., in the range of about 

regions for Random Access Memory (RAM) 216, Read- 12^16K). Such systems are well known in the art. 
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Having thus described an exemplary smartcard 100 and 10 and at least one partnering organization 12. Issuer 10 
IC 110, an overview of aTsma rteard^e gstruptureiin-ac cor^ suitably comprises various hardware and software compo- 
dance with the present invention will now be described. nents suitable for client host communications as well as a 
Referring now to FIG. 4, file structure 400 is preferably used database system 11 . In this context, the term 'issuer' refers 
to store information related to ^ca^holder^r^fergne^lalnd 5 to tDC organization that actually issues the smartcard and 
various data useful for securing and paying for air travel, retains high-level access to certain areas of file struc- 
rental cars, hotel reservations and the like. More particularly, ture 400 (detailed below). 
<^£UcEstinieUir^ Partnering organizations 12(a), 12(6), and so on, corn- 
cation 406, payment system application 408, airline appli- P rise the various hotel chains, rental-car agencies, airlines, 
cation 410, hotel system application 412, rental car appli- 10 ^ a ? css t0 a PP ro P riate data 
cation 414, and cardholder verification data 404. It will be ™ thm ^card 100 Each partnering organization 12 suit- 
appreciated by those skilled in the art that the term "appli^ M ? «»ipnses a database 13 and appropriate hardware and 
.c atianS*^^ software ^P 0 ™* necessary for completing a transaction 
data^^ over network 19 Network 19 may comprise one or more 
et^^^^^^^S^m^^s communion modes e.g., the public switched telephone 
although the use onx^ble^o^leTas part of any netwo * ( ps ]^> th e Internet, digital and analog wireless 
particular application falls within the scope of the present networks, and the like. 

flnV^gti oh — Z^z^z^ZZ^^ ^ acn access P omt 15 suitably comprises an appropriate 

Cardholder verification data 404 preferably houses data <ard reader for interfacing with smartcard 100 as well as 
useful in verifying cardholder identity during a transaction. 20 ^w«e and software suiUbk for mterfacmg with a card- 
In a preferred embodiment, cardholder verification data 404 h A ° lder and forming a transaction over network 19. 

r . , ... . . , , t . . Access points 15 are preferably located in areas providing 

comprises two eight-byte cardholder verification numbers s ^ c * J , . . * , b 

/• htm u J\ /_ a * rU vi a r-^in/o convenient access for traveling cardholder s or cardholder s 

(i.e., PIN numbers) referred to as CHV1 and CHV2. . A & 0 , . A 

x ' „ , , ' . . MAi0 . . , . . preparing travel arrangements. Such access points 15 may 

Cardholder ID application 406 suitably comprises various be located> for exampte in airline ticketing and gate areas> 

files related to personal ^formation of the cardholder (e.g. » ^ ^ fecfl . ^ ^ ^ ^ ^ 

name, addresses, payment carck driver s license, personal ^ m maUs In addition? businesses might see fit t0 

preferences and the like) Cardholder ID application 406 is host afl acccss M 15 lQ strcamlin6 ^ employ6CS > 

desenbed in greater detail below in conjunction with FIG. 5. business traveJ FuxaiBmoTC9 an individual cardholder might 

Payment system application 408 suitably comprises infor- ^ configure his or her personal computer to act as an access 

mation useful in effecting commercial transactions, e.g., po { nt appropriate software and peripheral hardware, 

account number and expiration date information tradition- In a p referred embodiment of the present invention, data 

ally stored on a magnetic-stripe credit card. Alternatively, fiks ^ di rectories are st0 red in a "tree" structure as 

Payment system application 408 comprises a fall EMV- flhlslrated m nG . 3. That is, the smartcard file structure 

compliant application suitable for a wide range of financial 3f . resembles me wcll ^ovm MS-DOS (Microsoft Disk Oper- 

transactions. Payment system application 408 is described ating System) file simcUlTQ wherein files are logically orga- 

further below in conjunction with FIG. 6. nizcd within a hierarchy of directories. Specifically, three 

Airline application 410 suitably comprises data helpful in types 0 f files are defined in ISO 7816-4: dedicated files (DF), 

streamlining commercial airline travel; for example, rel- elementary files (EF), and a master file (MF). The master file 

evant personal preferences, electronic tickets, and frequent 4Q & analogous to the MS-DOS "root" directory, and contains 

flier information. Airline application 410 is discussed in a u other files and directories. Dedicated files are actually 

greater detail below in conjunction with FIG. 7. directories or "folders" for holding other DFs or EFs. Thus, 

Hotel application 412 suitably comprises information MF 302 may contain an arbitrary number of DFs 306, and 

useful for securing and paying for hotel reservations, includ- these DFs (e.g M DF 306(a)) may or may not contain other 

ing an array of information and preferences associated with 45 DFs (e.g., DF 308). Elementary files are used to store user 

a fist of preferred hotels as well space for electronic keys. data, and may exist within a dedicated file (e.g., EF 310 

Hotel application 412 is discussed in greater detail below in within DF 306(a)), or within the master file (e.g., EF 304 

conjunction with FIG. 9. within MF 302). Higher level DFs (i.e., DFs which house 

Rental car application 414 suitably comprises data useful particular applications) are often referred to as application 

in expediting the process of car rental and return, including, 50 dedicated files (ADFs). 

for example, car preference and frequent rental information. The MF and each of the DFs and EFs are assigned a 
Rental car application 414 is described in further detail unique two-byte file identifier (FID). By convention, the MF 
below in conjunction with FIG. 8. is traditionally assigned an FID of '3F00' hex. Selection of 
In each of the above mentioned applications, sophisti- an EF or DF by the operating system may then be performed 
cated access and encryption schemes are preferably utilized 55 by tracing its entire path starting at the MF. Thus, if the MF 
in order to allow multiple parties to make use of certain file contains a DF with a FID 'A100 % and this DF in turn 
structures while preventing unauthorized entry into others. contains an EF or DF by the operating system may then be 
More specifically, partnering organizations (e.g., hotel performed by tracing its entire path successive selection of 
chains, airlines, and rental car agencies) may create their EIDs 3F00, A100, and A101. It will be appreciated that the 
own tailor-made file structures (i.e., "partner file structures") 60 FID is essentially a file name used by the operating system 
within card 100. Details of the various security measures select directories and files; it is not intended to indicate a 
employed are described in further detail below in conjunc- physical address within EEPROM 212. As will be appreci- 
tion with Table 40. ated by those skilled in the art, low-level EEPROM address- 
Referring now to FIG. 10, smartcard 100 is suitably used ing is preferably handled by the SCOS in conjunction with 
in the context of a distributed transaction system. Briefly, 65 CPU 202. 

cardholder's may employ smartcard 100 at various access Each file preferably has as associated file leader contain- 

points 15 which are connected via network 19 to an issuer ing various indicia of the particular EF, DF, or MF. More 
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particularly, the file header associated with a particular file 
preferably includes the file identifier (FID), file size, access 
conditions, and file structure. In this regard, smartcard 100 
suitably employs one of four file structures: transparent, 
linear fixed, linear variable, or cyclic. For the sake 5 
completeness, the nature of these file structures will be 
briefly reviewed. 

A transparent file structure consists of a string of bytes 
accessed by specifying an offset and byte count. For 
example, with reference to Table 1 below, given a n-byte 10 
string of data, bytes 7 through 10 would be accessed using 
an offiset of six and a length of four. 

TABLE 1 

15 

Transparent file structure 

byte# 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 n 

i i i i i i wmmmm i i i i i i t 20 



8 

8825 sets forth the basic encoding rules for a TLV system 
and defines a "template" data object which can be used as a 
container for multiple TLV objects. That is, it is often 
advantageous to encapsulate primitive TLV objects within a 
larger template which is itself a TLV object. 

Referring now to FIG. 4, a preferred smartcard data 
structure in accordance with the present invention will now 
be described in detail. Data structure 400 preferably com- 
prises a MF 402 and five DFs: Cardholder ID application 
406, Payment system application 408, Airline application 
410, Hotel application 412, and Rental car application 414. 

In the detailed description to follow, various acronyms 
and abbreviations will be used to refer to particular data 
types, formats, and the like. A key to these acronyms and 
abbreviations is presented in Table 3 below. 

TABLE 3 



Key to acronyms 



_i i mmmmm 

offset — --length — *» 



A linear fixed file structure comprises a plurality of 
records of equal length (e.g., a list of phone numbers), 
wherein access to an individual record is achieved through 
reference to a record number. In addition, it is possible to 
refer to the 'next' or 'previous* record relative to the 
'current* record (i.e., the most recently accessed record). In 
contrast, a linear variable file structure comprises records of 
arbitrary but known length, and is therefore typically more 
compact than linear fixed data structures. 

A cyclic file structure is a type of linear fixed file wherein 
a pointer is used to point to the last data set written to. After 
the last data record is written to, the pointer returns to the 
first record. That is, a cyclic file comprises a series of records 
arranged in a 'ring'. 

A data structure particularly important with regard to 
storing records as well as secure messaging in smartcard 
applications is the BER tag-length-value or "TLV" structure 
in accordance with ISO/IEC 8825, hereby incorporated by 
reference. In a TLV object, information regarding the type 
and length of the information is included along with the 
actual data. Thus, a TLV object comprises a tag which 
identifies the type of data (as called out by the appropriate 
specification), a length field which indicates the length in 
bytes of the data to follow, and a value field, which com- 
prises the primary data. For example, the TLV object illus- 
trated in Table 2 below encodes the text "phoenix", which 
has a length of 7 bytes, and corresponds to a the "city" tag 
of '8C hex (a hypothetical tag designation). 



TABLE 2 




ExempLarv primitive TLV object 






Length Value 




*8C 


'07' p h o e n 


X 



55 



60 



It will be appreciated that the meaning of the various tag 
values must be known to the system a priori. That is, in order 
for the tag field to be useful, the smartcard and any external 
systems communicating with the smartcard must conform to 
the same tag specification. In this regard, ISO/IEC 7816-6 65 
defines a series of tags useful in the context of the present 
invention, as does the IBM MFC 3.2 specification. ISO/IEC 



AN Alphanumeric 

N Numeric 

B Boolean 

C Convention 

M Matrix 

D Data 

AR Bits array 

BIN Binary 

RJ Right-justined 

U Left-justified 

BCD Binary coded decimal 



In the discussion that follows, the various features of a 
preferred data structure are in some cases described using 
particular file structure types (i.e., transparent, fixed, etc.). 
Those skilled in the art will realize, however, that any of the 
common smartcard file structure types are typically suitable 
for implementing any particular data structure. For example, 
when a file structure is described as including "a plurality of 
records," it will be understood that such a structure may be 
designed, for example, using a list of records assembled in 
a linear fixed file wherein each record is itself a transparent 
file (and offset values correspond to the various fields). 
Alternatively, such a structure may be designed using TLV 
strings assembled in a linear fixed file or within a larger 
template TLV. This is the case notwithstanding the fact that 
particular tag values — which are for the most part 
arbitrary — are not explicitly listed in the tables that follow. 
Cardholder ID Application 

Referring now to FIG. 5, Cardholder ID application 406 
is used to store various information related to the cardholder. 
Portions of this information are freely available to the 
partnering organizations, thereby preventing the storage of 
redundant information. 

More particularly, cardholder ID application 406 prefer- 
ably comprises directory EF 532, holder_ID DF 502 and 
miscellaneous DF 530. Holder_JD DF 502 preferably com- 
prises ID EF 504, home EF 506, business EF 508, prefer- 
ences EF 514, passport EF 516, authentication EF 520, 
biometric EF 522, and driver EF 518. Miscellaneous EF 530 
preferably comprises payment card EF 510, sequence EF 
512, issuance EF 511, preferred programs EF 528, and card 
number EF 526. These files and their respective functions 
are discussed in detail below. 

Directory EF 532 provides a list of application identifiers 
and labels for the various high-level DF's existing under 
cardholder ID application 406. That is, this file serves the 
function of a high-level directory listing which specifies the 
location (i.e., FID) and application label for each DF — in 
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this case, holder__ID DF 502 and miscellaneous DF 530. In 
a particularly preferred embodiment, directory EF 532 is 
structured in accordance with EMV 3.0 as shown in Table 4 
below Preferably, each major application (e.g., hotel, 
airline, etc.) has an associated directory file with a substan- 
tially same file structure. 



10 

TABLE 



Exemplary home EF 



TABLE 4 

Exemplary cardholder ID directory EF 10 



External Internal format 
format (bytes) 



Record description 


Size 


Type 


Size 


Type 


Application ID for holder_JD DF 


16 


AN 


16 


Ascn 


Application label 


16 


AN 


16 


ASCII 


Application ID for miscellaneous DF 


16 


AN 


16 


ASCII 


Application label 


16 


AN 


16 


ASCII 



15 



ID EF 504 preferably includes personal information 
related to the cardholder, e.g., name, date of birth, emer- 
gency contact, general preferences, and the like. In a par- 
ticularly preferred embodiment, member EF 504 comprises 
the fields set forth in Table 5 below. Italicized field names 
indicate a subcategory within a particular field. 

TABLE 5 



Exemplary ID EF data structure 

External Internal 
format format (bytes) 



Record description 


Size 


Type 


Size 


Type 


Last Name 


30 


AN 


30 


ASCII 


First Name 


20 


AN 


20 


ASCII 


Middle Name 


8 


AN 


8 


ASCII 


Honorary Title 


8 


AN 


8 


ASCII 


Name Suffix 


4 


AN 


4 


ASCII 


Date of Birth 


8 


D 


4 


BCD 


Social Security Number 


10 


AN 


10 


ASCII 


Emergency Contact 










Last Name 


20 


AN 


20 


ASCII 


First Name 


10 


AN 


10 


ASCII 


Relation 


1 


C 


1 


BIN 


Phone 


20 


N 


10 


BCD 


Gender 


1 


AN 


1 


ASCII 


Special Person Requirements 


12 


AN 


12 


M 


Language Preference (ISO 639) 


2 


C 


2 


ASCII 



In the above table, and the tables to follow, both internal 
and external data formats are listed. As the conservation of 
EEPROM space is of paramount importance, the "internal" 
format of data (i.e., within EEPROM 212) may be different 
from the "external" format of the data (i.e., as read by the 
card reader at an access point 15). Thus, for example, a date 
field might consist of a four-byte BCD record within the 
card, but upon reading and processing by the terminal, this 
data might be converted to an eight-byte decimal value for 
more convenient processing. 

Home EF 506 preferably includes data related to one or 
more of the cardholder's home addresses. In a particularly 
preferred embodiment, home EF 506 comprising the fields 
set forth in Table 6 below. The personal travel charge 
account pointer is preferably used to designate a preferred 
payment card, and consists of a number corresponding to 
one of the payment card records within payment card EF 510 
(detailed below). 



6 



file structure 



External Internal format 
format (bytes) 



Record description Size Type Size Type 



Home Address 1 


40 


AN 


40 


ASCII 


Home Address 2 


40 


AN 


40 


Asai 


Home Address City 


25 


AN 


25 


Asai 


Home Address State 


5 


AN 


5 


Asai 


Home Country (TSO 3166) 


2 


AN 


2 


Asai 


Home Address Zip Code 


10 


AN 


10 


Asai 


Home Address Telephone 


20 


N 


10 


BCD 


Home Address FAX 


20 


N 


10 


BCD 


Home E-mail addiess 


40 


AN 


40 


Asai 


Personal travel charge account number 


2 


N 


1 


BCD 



pointer 



Business EF 508 preferably includes various data related 
to the cardholder's business (i.e., addresses, phone numbers, 
and the like). In a particularly preferred embodiment, busi- 
ness EF 508 comprising the fields set forth in Table 7 below. 
In this regard, the credit card pointer field is preferably used 
to point to a payment card record within payment card EF 
510 (detailed below). The cost center, dept., division, and 
employee ID fields are employer-specific, and may or may 
not apply in a given case. 

TABLE 7 



Exemplary business EF file structure 

Internal format 
External format (bytes) 



Record description 


Size 


Type 


Size 


Type 


Business Address 1 


40 


AN 


40 


ACSII 


Business Address 2 


40 


AN 


40 


Asai 


Business Address City 


25 


AN 


25 


Asai 


Business Address State 


5 


AN 


5 


Asai 


Business Country (ISO 3166) 


2 


AN 


2 


Asai 


Business Address Zip Code 


10 


AN 


10 


Asai 


Business Telephone No. 


20 


N 


10 


BCD 


Business Address Fax 


20 


N 


10 


BCD 


Business E-mail Address 


40 


AN 


40 


Asai 


Professional Title 


10 


AN 


10 


Asai 


Employee ID 


10 


AN 


10 


Asai 


Division 


20 


AN 


20 


Asai 


Dept 


20 


AN 


20 


Asai 


Cost Center 


12 


AN 


12 


Asai 


Professional travel account number 


2 


N 


2 


BCD 


pointer 










Professional license data 


20 


AN 


20 


Asai 


Credit Card pointer 


2 


N 


1 


BCD 


Company Name 


20 


AN 


20 


Asai 



Preferences EF 514 preferably comprises data related to 
the cardholder's default personal preferences. In a particu- 
larly preferred embodiment, preferences EF 514 includes a 
field comprising an array of preferences as set forth in Table 
8 below. Preference values are preferably chosen from a list 
of preference tags as set forth in Table 39. 



25 



30 



35 



40 



45 



50 



55 



60 
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TABLE 8 



Examplarv preferences EF file structure 

Internal format 
External format (bytes) 

Record description Size Type Size Type 



Preferences Array 20 C 20 C 



Passport EF 516 is preferably used to store cardholder 
passport information. In a particularly preferred 
embodiment, passport EF 516 comprises the fields set forth 
in Table 9 below. 

TABLE 9 



Examplarv passport EF file structure 

External forma t Internal format (bytes) 



Record description 


Size 


Type 


Size 


Type 


Passport Number 


20 


AN 


20 


ASCII 


Passport Country ~ ISO 3166 


2 


AN 


2 


ASCII 


Issuance Date 


8 


D 


4 


BCD 


City of Issuance 


20 


AN 


20 


AN 


Expiration Date 


8 


D 


4 


BCD 



Driver EF 516 preferably comprises cardholder driver 
license data. In a particularly preferred embodiment, driver 
EF 518 comprising the fields set forth in Table 10 below. 



TABLE 10 



Exemplary driver EF file structure 

External Internal format 
format (bytes) 



Record description 


Size 


Type 


Size 


Type 


Driver's License No. 


20 


a 


20 


ASCII 


Driver's Licease Issuing State/Country 


2 


a 


2 


BCD 


License Expiration Date 


8 


D 


4 


ASCII 


License Type 


2 


C 


4 


BCD 



Biometric EF 522 is used to store biometric data 
(preferably encoded) such as fingerprint data, retina scan 
data, or any other sufficiently unique indicia the cardholder's 
physical or behavioral characteristics. In a particularly pre- 
ferred embodiment, biometric EF 522 comprises a single 
data string as set forth in Table 11 below. 



TABLE 11 



Exemplary biometric EF file structure 


External format 


Internal format (bytes) 


Record description Size Type 


Size Typ c 


Biometrics template 100 AN 


100 BIN 



Authentication EF 520 preferably comprises information 
for static authentication of the cardholder ID 406 applica- 
tion. This data is unique for each card, and is sufficiently 
complex such that counterfeit values cannot feasibly be 
created. This prevents creation of "new" counterfeit cards 
(i.e., cards with new authentication data), but does not 
prevent creation of multiple copies of the current card. 

In a particularly preferred embodiment, authentication EF 
520 includes public key certificate fields as shown in Table 



12 below, wherein the external format is identical to the 
internal format. Preferably, the issuer RSA key is 640 bits 
long, and the CAkey is 768 bits long. 

5 TABLE 12 



Exemplary authentication EF 

Internal format (bytes) 



10 



15 



Record description 


Size 


Type 


Signed Static Application Data 


80 


B 


Static Data Authentication Tag List 


16 


B 


Issuer Public Key Certificate 


96 


B 


Issuer Public Key Exponent 


1 


B 


Issuer Public Key Remainder 


20 


B 



Turning now to files under miscellaneous DF 530, pre- 
ferred programs EF 528 preferably comprises data related to 
the cardholder's preferences as to airline companies, hotels, 
and rental car agencies. Specifically, this EF, in a particularly 
preferred embodiment, comprises a plurality of records (e.g., 
three) indicating preferred companies for each type of travel 
partner as shown in Table 13. The actual data values 
conform to an arbitrary convention; that is, each airline, 
hotel, and rental car agency is assigned an arbitrary three- 
byte code. 

TABLE 13 



Exemplary programs EF 

30 

Internal format 
External format (bytes) 



35 



Record description 


Size 


Type 


Size 


Type 


Preferred Airlines 


9 (3 x 3) 


C 


9 


C 


Preferred Hotels 


9 


C 


9 


C 


Preferred Rental Cars 


9 


c 


9 


C 



Payment card EF 510 is preferably used to catalog infor- 
mation related to the cardholder's various payment cards, 

4 i.e., debit cards, charge cards, and the like. In a particularly 
preferred embodiment, payment card EF comprises card 
numbers and expiration dates for two cards as shown in 
Table 14. The "ISO" and "non-ISO" designations refer to 
ISO-7813, which specifies a particular payment card number 

45 format. Thus, in a preferred embodiment, either an ISO or 
non-ISO card number scheme may be used. Moreover, it 
will be appreciated that this data set is sufficient only for 
"card not present" transactions, for example, transactions 
taking place remotely where only the card number and 

50 expiration date are required to effect a transaction. Data 
stored within payment system application 408 (described 
below) must be used to effect a "card present" transaction. 



TABLE 14 

55 

Exemplary payment card EF file structure 



60 





External 


Internal format 




format 


fbvtes^ 


Record description 


Size Type 


Size Type 


First Payment Card # (ISO) 


19 N 


10 BCD 


First Payment Card Expiration Date 


8 D 


4 BCD 


Second Payment Card # (non-ISO) 


20 AN 


20 ASQI 


Second Payment Card Expiration Date 


8 D 


4 BCD 



65 

Sequence EF 512 preferably includes information used to 
provide synchronization of the host and smartcard data- 
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bases. In a particularly preferred embodiment, sequence EF 
512 comprises a plurality of records comprising the field set 
forth in Table 15 below. This number is analogous to a 
"version" number for the data stored in the application. 

TABLE 15 



Exemplary sequence EF file structure 


External format 


Internal format (bytes') 


Record description Size Type 


Size Type 


Sequence Number 16 AN 


16 ASCII 



Card number EF 526 is used to record a unique number 
identifying the smartcard, and may also be used for key 
derivation (as described in further detail below). Preferably, 
card number EF 526 comprises a eight-byte string as set 
forth in Table 16 below. 



TABLE 16 





Exemplary card number EF 




External format 


Internal format fbvtes) 


Record description 


Size Type 


Size Type 


Card Number 


8 HEX 


8 HEX 



TABLE 17 



Exemplary issuance EF file structure 



External format 



Internal format 
festes) 



Field 


Size 


Type 


Size 


Type 


Country Authority 




ISO 3166 


2 




Issuer Authority 


10 


RID - ISO 


5 


HEX 






7816-5 






Application version 


5 


XX. YY 


2 


BCD 


Application expiration date 


8 


YYYYMM 


4 


BCD 






DD 






Application effective date 


8 


YYYYMM 


4 


BCD 




DD 






Personalizer Code 


1 


AN 


1 


ASCII 


Personalization Location 


1 


AN 


1 


ASCII 



10 



15 



Issuance EF 511 is used to record various details related 
to the manner in which the application (i.e., cardholder ID 
DF 406) was created. This file includes information related 
to the identity of the organization that created the 
application, as well as information related to the application 
itself. In a particularly preferred embodiment, issuance EF 35 
511 comprises fields as set forth in Table 17 below. 



The personalizer code field shown in Table 17 refers to the 
organization that actually "personalizes" the file. That is, 
before a smartcard may be issued to the cardholder, the 
database structure must be created within EEPROM 212 
(FIG. 2), and the initial data values (i.e., default preferences, 
cardholder name, pin numbers, etc.) must be placed in the 
appropriate fields within the various EFs. It will be appre- 
ciated that, given the nature of the present invention, the 
smartcard "issuer" and "personalizer" for any given appli- 
cation may not be the same. Therefore, it is advantageous to 
record various details of the personalization process within 
smartcard 100 itself. Similar issuance file structures may be 
provided for the other major applications. 



45 



50 



55 



60 



65 
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Payment System Application 

Referring now to FIG. 6, payment system application 408 
preferably comprises a directory EF 610, issuer DF 602, and 
a number of optional DFs 603(a)-(n) for use by partnering 
financial organizations. 

Directory EF 610 preferably includes a list of application 
identifiers and labels as described above in the context of 
cardholder ID application 406. 

Issuer DF 602 comprises payl DF 604, which includes 
data that would traditionally be stored within tracks on a 
magnetic stripe card (i.e., debit cards, charge cards, and the 
like). In a preferred exemplary embodiment, payl DF 604 
comprises a plurality of records having commonly known 
magnetic-stripe fields as specified in Table 18 below, 

TABLE 18 



20 



Exemplary Payl EF file structure 



Record description 



External format 
Type 



Internal format 
fbYfoO 



Size 



Size Type 



25 Format Code (Track 1) 


1 


AN 


1 


ASCII 


PAN (Track 2) 


15 


N 


8 


BCDF 

right 

padding 


Expiration date (Track 1 or 2) 


4 


YYMM 


2 


BCD 


Effective date (Track 1 or 2) 


4 


YYMM 


2 


BCD 


30 Discretionary data (Track I or 2) 


5 


N 


3 


BCDF 








right 
padding 


Name (Track 1) 


26 


AN 


26 


ASCII, U 

blank 

padding 



Airline Application 

Referring now to FIG. 7, airline application 410 prefer- 
ably comprises directory EF 730, common DF 702, and 
issuer DF 704, and additional airline applications 703(a), 
703(b), and so on. 

Directory EF 730 preferably includes a list of application 
identifiers and labels as described above in the context of 
cardholder ID application 406. 

Common DF 702 generally includes data accessible to all 
participating airlines, while issuer DF 704 generally 
includes data which can only be read or written to by the 
smartcard issuer. Airline application 410 preferably further 
comprises at least one (preferably three) additional DF 703 
for use by airline partnering organizations. That is, one 
airline partner may have access to and specify the structure 
of data stored within DF 703(a) (as well as common EF 
702), while another airline might have similar access to DF 
703(6). These partner DFs preferably conform to the rel- 
evant portions of the I ATA specification. 

Common DF 702 suitably comprises common data which 
would be of use to any of the various partnering airlines, i.e., 
passenger EF 706, frequent flier EF 708, IET EF 710, 
boarding EF 712, and biometric EF 714. 

Issuer DF 704, in contrast, comprises information read- 
able by all, but updatable only by the card issuer, i.e., 
preferences EF 716, PIN EF 718, and issuance EF 720. 

Referring now to information stored within common EF 
702, passenger EF 706 preferably comprises various records 
related to the passenger as specified in Table 19 below. 
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TABLE 19 



16 



Exemplary passenger EF file structure 



particularly preferred embodiment, biometric EF 714 com- 
prises data as specified in Table 23 below. 

TABLE 23 



Internal 





External format 


format (bytes) 


Exemplary biometric EF file structure 


Record description 


Size 


Type 


Size 


Type 




Internal 


Passenger Name 


49 


AN 


49 


asqi 


External format 


format (bytes) 


Gender 


1 


A 


1 


BIN 10 






Language Preference 
Unique ID 


2 

24 


AN 
AN 


2 
24 


asqi 
asqi 


Record description Size Type 


Size Type 


Airline ID (3 letters code) 
Type code (2 letters) 
Unique ID 
Application version 


3 
2 
19 
2 


AN 
AN 
AN 
N 


3 
2 
19 
2 


asqi 
asqi 
Asai 


Biometrics data 100 AN 


100 BIN 


bin 15 







In a particularly preferred embodiment, frequent flyer EF 
708 comprises a plurality of frequent flier numbers (e.g., ten 
numbers) having the structure specified in Table 20 below. 

TABLE 20 



Exemplary frequent flyer EF file structure 

Internal 

External format format (bytes) 

Record description Size Type Size Type 
Airline Customer ID 22 AN 22 ASCII 



IET EF 710 preferably comprises a plurality of electronic 
ticket records as set forth in Table 21 below. The format of 
these electronic tickets preferably conforms to the IATA 
standard. 

TABLE 21 



Exemplary IET file structure 

Internal 

Exterpat format format (bytes) 



Description of the records 


Size 


Type 


Size 


Type 


IET1 


14 


AN 


14 


BIN 


IET 2 


14 


AN 


14 


BIN 


IET 3 


14 


AN 


14 


BIN 


IET 4 


14 


AN 


14 


BIN 


IET 5 


14 


AN 


14 


BIN 



In a particularly preferred embodiment, boarding EF 712 
comprises boarding data to be used during check in as 
specified in Table 22. The format of this data preferably 
conforms to the LATA specification. 

TABLE 22 



Exemplary boarding EF file structure 

Internal 

External format format (bytes) 

Record description Size Type Size Type 

Boarding data 40 AN 40 ASCII 



Biometric EF 714 is suitably used to store biometric data 
associated with the cardholder, e.g., retina scan data, fin- 
gerprint data, or any other sufficiently unique indicia of the 
cardholder's physical or behavioral characteristics. In a 



Issuance EF 720 is suitably used to hold data related to the 
issuance of the various applications. In a particularly pre- 
2Q ferred embodiment, issuance EF 720 comprises a data 
structure as specified in Table 24 below. 

TABLE 24 

Exemplary issuance EF file structure 

25 

Internal 

External format format (bytes) 



35 



Field 


Size 


Type 


Size 


Type 


Country Authority (2 letters) 




ISO 3166 


2 




Issuer Authority 


10 


RID - ISO 


5 


HEX 






7816-5 






Application version 


5 


XX.YY 


2 


BCD 


Application expiration date 


8 


YYYYMM 


4 


BCD 






DD 






Application effective date 


8 


YYYYMM 


4 


BCD 




DD 






Personal izer Code 


1 


AN 


1 


ASCII 


Personalization Location (custom 


1 


AN 


1 


ASCII 



code) 



40 

PIN EF 718 is suitably used to store PIN values corre- 
sponding to each of the participating airline partners. In a 
particularly preferred embodiment, PIN EF 718 comprises a 
45 plurality of records having the structure specified in Table 25 
below, wherein each record is related to the corresponding 
entry in frequent flyer EF 708 (i.e., record one in EF 718 
corresponds to record one in EF 708, and so on.) 

50 TABLE 25 

Exemplary PIN EF file structure 



Internal 

External format format (bytes) 



Record description 


Size 


Type 


Size 


Type 


PIN 


8 


AN 


8 


BIN 


Expiration date 


8 


D 


4 


BCD 



60 



Preferences EF 716, in a particularly preferred 
embodiment, comprises a preferences array as shown in 
65 Table 26 below. The preference values stored in this file 
correspond to those discussed below in conjunction with 
Table 38. 
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TABLE 26 



Exemplary preferences EF 716 file structure 



Record description 



External format 



Internal 
format (bytes) 

Size Type 



Preferences Array 



30 



TABLE 27 



Record description 



Exemplary preferences EF 

External 
format 



Internal 
format (bytes) 



Preferences Array (Default) 


8 


C 


8 


BIN 


Preferences Array (No. 2) 


8 


c 


8 


BIN 


Prefeienccs Array (No. 3) 


8 


c 


8 


BIN 


Preferred limousine company 


12 


AN 


12 


ASCH 



Rental_car_jd 807 is used to store frequent rental 
information, upgrade information, insurance information, 
and the like. In a particularly preferred embodiment, rental_ 
car_id 807 comprises a file structure as shown in Table 28 
below. 

TABLE 28 



Record description 



Exemplary rental_car Jd EF 

External 
format 



Internal 
format (bytes) 



Frequent Rental ID# 


22 


A 


22 


ASCH 


Company name 


3 


A 


3 


Ascn 


Unique Customer ID 


19 


A 


19 


ASCII 


CDP (Contract Disc. Program) 


10 


A 


10 


ASCII 


Accumulated points 


8 


N 


3 


BIN 


Rental features 




AR 


2 


BIN 


Car Type Upgrade 




B 


1 bit 


B 


Week-end/Vacation Special 




B 


1 bit 


B 


Guaranteed Late Reservation 




B 


1 bit 


B 


Insurance 




Array 


2 


BIN 


Loss Damage Waiver (LDW) 




B 


1 bit 


B 


Personal Automobile Insurance 




B 


1 bit 


B 


Personal Effects Coverage 




B 


1 bit 


B 


Personal Insurance 




B 


lbit 


B 


Corporate Insurance 




B 


1 bit 


B 



15 



Rental Car Application 

Referring now to FIG. 8, rental car application 414 
preferably comprises common DF 802, directory EF 820, 
and one or more rental_car DFs 803 (i.e., 803(a), 803(6), 
and so on) corresponding to individual rental car agencies. 

Common DF comprises preferences EF 805, which is 
described in detail below. Rental_car DFs 803 each com- 
prise a rental_car_Jd EF 807, reservation EF 809, and 
expenses EF 811. 

Directory EF 820 includes a list of application identifiers 20 
and labels for the various DFs under rental_car application 
414. The structure of this EF preferably conforms to that 
described above in the context of cardholder ID application 
406. 

In a particularly preferred embodiment, preferences EF 25 
805 comprises a set of preferences arrays file structure as 
shown in Table 27 below. A preferred list of preference 
codes for use in each of these arrays is described below in 
conjunction with Table 38. 



30 



40 



Reservation EF 809 is used to store confirmation numbers 
corresponding to one or more rental car reservations. In a 
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particularly preferred embodiment, reservation EF 809 com- 
prises a plurality of records (e.g., two) having a file structure 
as shown in Table 29 below. 

TABLE 29 

Exemplary reservation EF 



65 



Record description 




External 
format 


Internal 
format (bytes) 


Rental Car Company 


3 


A 


3 


ASCII 


Location 


3 


A 


3 


ASCII 


Date 


8 


D 


4 


BCD 


Time 


4 


T 


2 


BCD 


Reservation Number 


15 


A 


15 


ASCII 


Flight Number 


5 


M 


5 


BIN 


Airlines 


3 


AN 


3 


ASai(RJ) 


Flight number 


4 


K 


2 


BCD 


Preferred profile 


1 


C 




ASCII 



Expenses EF 811 is used to record expenses incurred by 
the cardholder during car rental (e.g., the total rental charge). 
In a particularly preferred embodiment, expenses EF 811 
comprises a plurality of records (e.g., five) having a file 
structure as shown in Table 30 below. 



TABLE 30 




Exemplary expenses EF 






External 


Internal 


Record description 


format 


format (bytes) 


Type of expense 
Date 

Location code 
Amount 


1 C 
8 D 
3 AN 
7 N 


1 ASCII 
4 BCD 
3 ASCII 
3 BIN 



Hotel Application 

Referring now to FIG. 9, hotel system application 412 
preferably comprises directory EF 920, common DF 914, 
one or more hotel chain DFs 902, and one or more property 
DFs 903. 

Common DF 914 comprises reservation EF 918, expenses 
EF 916, key-of-the-room EF 910, and preferences EF 912. 

Hotel chain EFs 902(a), 902(b), and so on, comprise 
preferences EF 904 and stayer ID EF 906 associated with 
individual hotel chains. In contrast, property EFs 903(a), 
45 903(6), and so on, comprise a similar file structure associ- 
ated with individual hotel properties (i.e., independent of 
whether the particular hotel is a member of a nationwide 
chain). 

In a particularly preferred embodiment, reservation EF 
50 918 comprises a plurality of records having the structure 
shown in Table 31 below. In general, this EF is used to store 
confirmation numbers transmitted to smartcard 100 when 
the cardholder makes a reservation at a given hotel 
(designated in the property code field). The date field stores 
the date on which the confirmation number was dispensed. 



55 



60 



TABLE 31 



Exemplary reservation EF 

Internal 

External format format (bytes) 



Record description 


Size 


Type 


Size 


Type 


Property Code 


3 


AN 


3 


ASCII 


Date 


8 


D 


4 


BCD 


Confirmation Number 


15 


AN 


15 


ASCII 
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Preferences EF 912 preferably comprises three sets of 
array preferences. The particular codes used in these arrays TABLE 35 

are discussed below in conjunction with Table 38. ^ 



Exemplary stayer ID EF 

TABLE 32 5 internal 

' i ■ External format format (bytes) 

Exemplary preferences EF . , _ _ 
— --- Record description Size Type Size Type 



Internal 

External format format (bytes) 



Record description 


Size 


Type 


Size 


Type 


Preferences Array (default) 


8 


C 


8 


BIN 


Preferences Array (number 2) 


8 


C 


8 


BIN 


Preferences Array (number 3) 


8 


C 


8 


BIN 



Expenses EF 916 preferably comprises a list of recent 
hotel expenses, for example, room costs, dinner expenses, 
and the like. In a particularly preferred embodiment, 
expenses EF 916 comprises a plurality of records (for 
example, fifteen) arranged in a cyclic file structure and 
comprising the fields shown in Table 33 below. Thus, the 
cardholder is able to examine and print a list of recently 
incurred expenses by type (a code fixed by convention), 
date, amount, and property code. 

TABLE 33 

Exemplary expenses EF 



Internal 

External format format (bytes') 



Record description 


Size 


Type 


Size 


Type 


Type 


1 


C 


1 


ASCII 


Date 


8 


D 


4 


BCD 


Property Code 


3 


AN 


3 


ASCII 


Amount 


7 


N 


3 


BIN 



Key-of- the -room EF 910 preferably comprises electronic 
key values that can be used in conjunction with card readers 
to provide access to particular hotel rooms. In a particularly 
preferred embodiment, key-of-the-room EF 910 comprises a 
plurality of alphanumeric key values as shown in Table 34 
below. 

TABLE 34 
Exemplary kev-of-the-room EF 

Internal 

External format format (bytes) 

Record description Size Type Size Type 
Key value 40 AN 40 BIN 



Stayer ID EF 906 preferably comprises frequent stayer 
data for a particular hotel chain. In a particularly preferred 
embodiment, Stayer ID EF 906 comprises frequent stayer 
information as shown in Table 35 below. 



Frequent stayer number 


19 


AN 


19 


ASCII 


Frequent Stayer Level Code 


1 


• AN 


1 


ASCII 


Frequent Stayer Level Expiration 


6 


YYYYMM 


3 


BCD 


Date 










CDP 


10 


AN 


10 


ASCII 


Event Counter 


3 


N 


1 


BIN 


Hotel Frequent Stayer PIN 


8 


AN 


8 


BIN 



15 



Preferences EF 904 preferably comprises three sets of 
array preferences as shown in Table 36. The particular codes 
used in these arrays are discussed below in conjunction with 
Table 38. 



TABLE 36 
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Exemplary preferences EF 








Internal 




External format 


format (bytes') 


Record description 


Size 


Type 


Size Type 


Preferences Array (default) 


8 


C 


8 BIN 


Preferences Array (number 2) 


8 


C 


8 BIN 


Preferences Array (number 3) 


8 


c 


8 BIN 



Property DFs 903(a), 903(6), etc., are used in cases where 
the partnering hotel is not part of a major chain, or when the 

35 hotel chooses to employ its own data set independent of its 
affiliation. In one embodiment, these property DFs are 
identical in structure to hotel chain DFs 902, except that 
much of the frequent stayer ID information is removed. 
More specifically, a typical property DF 903 comprises a 

40 preferences EF 938 identical to preferences 904 described 
above, along with a stayer ID EF 934 which includes only 
the CDP, event counter, and hotel frequent stayer PIN fields 
described in conjunction with Table 33 above. Alternatively, 
a particular hotel chain or property might choose to imple- 

45 ment a different file structure than that described above. 
Preference Codes 

As mentioned briefly above, a preferred embodiment is 
configured such that preferences are located in several files 
distributed throughout smartcard 100; i.e., in preferences EF 

50 514, airline preferences EF 716, hotel preferences EF 912 
and 904, and car preferences EF 810. This allows apparently 
conflicting preferences to coexist within the card depending 
on context. For example, it is possible to opt for non- 
smoking in the cardholder ID application while choosing the 

55 smoking option within the hotel application. In the case of 
conflict, preferences are read from the top level to the 
bottom level, and each level supersedes the previous one. 

An exemplary set of codification rules are set forth in 
Table 37 below: 

60 

TABLE 37 

Exemplary Preferences Code Ranges 

0-49 General purpose (Cardholder ID 406) 

6S 50-99 Hotel application 412 

100-149 Rental car application 414 
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TABLE 37-coatimied 



Exemplary Preferences Code Ranges 
150-199 Airline application 410 

200-255 Other 



More specifically, in a preferred exemplary embodiment, 
preference flags are coded as set forth in Table 38 below. 



TABLE 38 


Exemplary preference codes 




Preference 


Code (decimal) 


GENERAL PURPOSE 




Smoking 


00 


Non-smoking 


01 


Home as preferred address 


02 


Work as preferred address 


03 


Handicapped 


04 


Home as preferred e-mail address 


05 


Work as preferred e-mail address 


06 


HOTEL PREFERENCES 




King-size bed 


50 


Queen-size bed 


51 


Double bed 


52 


High floor room 


53 


Low floor room 


54 


Near elevator room 


55 


Away from elevator room 


56 


RENTAL CAR PREFERENCES 




Compact car 


100 


Standard car 


101 


Mid-size car 


102 


Luxury car 


103 


AIRLINE PREFERENCES 




Window seat preferred 


150 


Aisle seat preferred 


151 


Low calorie 


152 


Vegetarian 


153 


Diabetic 


154 


Low sodium 


155 


Kosher 


156 



Security 

In the context of smartcard transactions, data security has 
five primary dimensions: 1) data confidentiality, 2) data 
integrity, 3) access control, 4) authentication, and 5) non- 
repudiation. Each of these dimensions is addressed through 
a variety of security mechanisms. Data confidentiality, 
which deals with keeping information secret (i.e., unread- 
able to those without access to a key), is substantially 
ensured using encryption technology. Data integrity (and 
data source verification) focuses on ensuring that data 
remains unchanged during transfer, and typically employs 
message authentication techniques. Access control involves 
card holder verification and other requirements necessary in 
order for a party to read or update a particular file. Authen- 
tication involves ensuring that the card and/or the external 
device is what it purports to be, and non-repudiation deals 
with the related task of ensuring that the source of the data 
or message is authentic, i.e., that a consumer may not 
repudiate a transaction by claiming that it was "signed" by 
an unauthorized party. 

Authentication is preferably performed using a 
"challenge/response" algorithm. In general, authentication 
through a challenge/response system involves: 1) generation 
of a random number by a first party; 2) transmission of the 
random number to a second party (the "challenge", 3) 
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encryption of the random number by the second party in 
accordance with a key known to both parties, 4) transmis- 
sion of the encrypted random number to the first party (the 
"response"), 5) encryption of the random number by the first 
5 party, and 6) comparison by the first party of the two 
resulting numbers. In the case where the two numbers 
match, authentication is successful; if not, the authentication 
is unsuccessful. Note that authentication can work both 
ways: the external world might request authentication of a 
smartcard (internal authentication), and a smartcard might 
request authentication of the external world (external 
authentication). A more detailed account of a preferred 
challenge/response algorithm can be found in the IBM MFC 
specification. 

In a preferred embodiment, the DES algorithm (Data 

15 Encryption Standard) is employed for the various security 
functions; however, it will be appreciated that any number of 
other symmetrical or asymmetrical techniques may be used 
in the context of the present invention. More particularly, 
there are two general categories of encryption algorithms: 

20 symmetric and asymmetric. Symmetric algorithms use the 
same key for encryption and decryption, for example, DEA 
(data encryption algorithm) which uses a 56-bit key to 
encrypt 64-bit blocks of data. Asymmetric algorithms, in 
contrast, use two different keys: one secret key and one 

25 public key. The RSA algorithm, for example, uses two such 
keys and exploits the computational complexity of factoring 
very large prime numbers. Additional information these and 
other cryptographic principles can be found in a number of 
standard texts, for example: Seberry & Pieprzyk, Cryptog- 

30 RAPHY: An Introduction to Computer Security (1989); 
Rhee, Cryptography and Secure Communications 

(1994) ; Stinson, Cryptography: Theory and Practice 

(1995) ; Contemporary Cryptography: The Science of 
Information Integrity (1992); and Schneier, Applied 

35 Cryptography (2d ed. 1996), the contents of which are 
hereby incorporated by reference. 

Access control is suitably provided by including access 
conditions within the header of each EF and DF. This 
prevents a particular operation (e.g., reading or updating) 

40 from being performed on a file unless the required access 
conditions have been fulfilled. Many different access con- 
ditions are appropriate in a smart card context. For example, 
the smartcard might require cardholder verification (i.e., 
request that the cardholder enter a PIN) before a file opera- 

45 tion is allowed. Similarly, internal and/or external authenti- 
cation as described above might be required. 

Another important access condition (referred to herein as 
the SIGN condition) corresponds to the case where a par- 
ticular file is "protected" and where updating of a record 

so requires "signing" of the data using a message authentica- 
tion code (MAC), a MAC can be thought of as a form of 
electronic seal used to authenticate the content of the mes- 
sage. In a paradigmatic signing procedure, a shortened, 
encrypted representation of the message (the MAC) is 

55 created using a message authentication algorithm (MAA) in 
conjunction with a key known to both the card and external 
device. The MAC is then appended onto the message and 
sent to the card (or external device, depending on context), 
and the card itself generates a MAC based on the received 

60 message and the known key. The card then compares the 
received MAC with the its own internally-generated MAC. 
If either the message or MAC was altered during 
transmission, or the sending party did not use the correct 
key, then the two MACs will not match, and the access 

65 condition will not be fulfilled. If the two MACs correspond, 
then the access condition is fulfilled, and the particular file 
operation can proceed. 
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A MAC may be generated using a variety of MAAs, for 
example, the ANSI X9.9 method using an eight-byte key, or 
the ANSI X9.19 method using a sixteen-byte key. 
Furthermore, the actual key may be "diversified" through 
encryption with a random number or other appropriate 
value. These and other details regarding MAC generation 
can be found in the references cited above as well as the IBM 
MFC specification. 

Two other important access conditions are the NEVER 
and FREE conditions. The NEVER condition corresponds to 
the case where a certain file operation (typically updating) is 
never allowed. The FREE condition, on the other hand, 
corresponds to the case where either updating or reading a 
file record is always allowed, without any additional pre- 
conditions for access. 

In contrast to the MAC techniques discussed briefly 
above, non-repudiation is necessarily performed using 
asymmetrical techniques. That is, as symmetrical techniques 
such as MAC "sealing" use a key known to more than one 
party, such techniques can not be used by a third party to 
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ascertain whether the source of the message is correct. Thus, 
non-repudiation typically employs a public key encryption 
scheme (e.g., the Zimmerman's PGP system), wherein the 
sender uses a secret key to "sign" the message, and the 
receiving party uses the corresponding public key to authen- 
ticate the signature. In the context of the present invention, 
this function is suitably performed by allocating an EF for 
public and secret key rings, which are well known in the art, 
along with suitable encryption software resident in the card 
for assembling the signed message. 

Having thus given a brief overview of typical smartcard 
security procedures, an exemplary set of access conditions is 
set forth below in Table 40. In this regard, the various access 
conditions for each EF are tabulated with regard to whether 
the file is being read or updated. In each case, the access 
condition (FREE, SIGN, etc.), key "owner" (issuer, partner, 
user, etc.), and key name are listed. In this regard, it will be 
appreciated that the key name is arbitrary, and is listed here 
for the sake of completeness. 



TABLE 40 



Exemplary access conditions 

READING UPDATING 



Access Access 

condition Owner Key condition Owner Key 

MF 

DF Cardholder ID 406 
DF Holder_JD 502 



EF ID 504 


FREE 


SIGN 


ISSUER 


KEY1 


EF Home 506 


FREE 


SIGN 


ISSUER 


KEY1 


EF Business 508 


FREE 


SIGN 


ISSUER 


KEY1 


EF Preferences 514 


FREE 


SIGN 


ISSUER 


KEY1 


EF Passport 516 


FREE 


SIGN 


ISSUER 


KEY1 


EF Biometrics 522 


FREE 


SIGN 


ISSUER 


KEY1 


EF Driver 518 


FREE 


SIGN 


ISSUER 


KEY1 


DF Miscellaneous 










EF Payment card 510 


FREE 


SIGN 


ISSUER 


KEY1 


EF Sequence 512 


FREE 


FREE 






EF Card Number 526 


FREE 


SIGN 


ISSUER 


KEY1 



DF Payment System 408 
DF Issuer 602 



EF Payl 604 FREE FREE 

DF Airline 410 
DF Common 702 



EF Passenger 706 FREE 

EF Frequent flier 708 FREE 

EF IET 710 FREE 

EF Boarding 712 FREF 

EF Biometric 714 FREE 
DF Issuer 704 



SIGN ISSUER 

SIGN ISSUER 

FREE 

FREE 

FREE 



KEY2 
KEY2 



EF Preferences 716 
EF PIN 718 
EF Issuance 720 
DF Rental car 414 
DF Common 802 



FREE 
FREE 
FREE 



EF Preferences 805 
DF RentaLcar 803 



FREE 



SIGN ISSUER KEY2 
SIGN ISSUER KEY2 
SIGN ISSUER KEY2 



USER 



I DENT 



PIN 



EF Rental_car_ID 807 FREE 
EF Reservation 809 FREE 
EF Expenses 811 FREE 



DF Hotel system 412 



SIGN 

FREE 

SIGN 

(append) 

I DENT 

(erase) 



RENTCAR KEY6 



RENTCAR 
(append) 
USER 
(erase) 



KEY6 
(append) 
PIN 
(erase) 
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TABLE 40-continued 



Exemplary access conditions 



Access 



Access 





condition Owner 


Key condition 


Owner 


Key 


DF Common 914 










EF Reservation 918 


FREE 


FREE 






EF Expenses 916 


FREE 


FREE 


USER 


PIN 






(append) 


(erase) 


(erase) 






IDENT 










(erase) 






EF Key-of-the-room 910 


FREE 


FREE 






EF Preferences 912 


FREE 


SIGN 


ISSUER 


KEY1 


DF Hotel_cbain 902 










EF Preferences 904 


FREE 


SIGN 


ISSUER 


KEY1 


EF Stayer ID 906 


FREE 


SIGN 


HOTEL 


KEY5 



Transactions 

Having thus given a detailed description of an exemplary 
smartcard 100 and a preferred data structure 400, the various 
details related to transactions involving smartcard 100 will 25 
now be described. In general, a typical smartcard session 
involves: (1) activation of the contacts (or comparable 
non-contact means); (2) card reset; (3) Answer to reset 
(ATR) by card; (4) Information exchange between card and 
host; and, at the conclusion of a session, (5) deactivation of 30 
contacts. 

First, card 100 is inserted in a card reader provided at an 
access point 15, and suitable connections are made between 
communication region 104 on card 100 and the card reader. 
In a preferred embodiment, physical contacts (contacts 106 35 
in FIG. 1) are used, and DATA, CLOCK, RESET, VDD, and 
GND connections are made. These contacts are electrically 
activated in a particular sequence, preferably in accordance 
with ISO 7816-3 (RST to low state, VDD powered, DATA 
to reception mode, then CLK applied). 40 

The card reader then initiates a reset (i.e., R§T to high 
state), and the card returns an answer to reset string (ATR) 
on the DATA line, preferably in conformance with the 
content and timing details specified in the appropriate parts 
of ISO 7816. In a preferred embodiment, the interface 45 
characters are chosen to reflect a T=l protocol 
(asynchronous, half-duplex, block-oriented mode). Further 
in accordance with ISO-7816-3, after the card sends an ATR 
string and the proper protocol is selected (in a preferred 
embodiment, the T«l mode), host 314 and card 100 begin 50 
the exchange of commands and responses that comprise a 
particular transaction. The nature of these commands is 
discussed in further detail below. 

At the end of a smartcard session, contacts 106 are 
deactivated. Deactivation of contacts 106 is preferably per- 55 
formed in the order specified in ISO 7816-3 (i.e., RST to low 
state, CLK to low state, DATA to low state, VDD to inactive 
state). As mentioned above, the VPP contact is not utilized 
in a preferred embodiment. 

In the context of the present invention, command classes 60 
and instructions are provided for 1) working with applica- 
tion data (i.e., files stored within the various applications), 2) 
ensuring data security, 3) card management, and 4) perform- 
ing miscellaneous functions. 

Application data commands are suitably directed at 65 
selecting, reading, and updating individual records or groups 
of records within files. Security commands suitably include 



commands for performing the challenge/response authenti- 
cation process, generating random numbers, loading or 
updating cryptographic keys, and changing and verifying the 
card-holder verification codes (CHV1 and CHV2). Card 
management commands suitably include commands which 
allow for the creation and deletion of directories (DFs) and 
elementary files (EFs). Miscellaneous commands are suit- 
ably provided for modifying the baud rate and reading 
various card statistics (e.g., data logged during production of 
the card.) It will be appreciated that many different com- 
mand sets could be designed for implementing these basic 
functions. One such command set is provided by the IBM 
Multifunction Card Operating System 3.51, hereby incor- 
porated by reference. 

Referring again to FIG. 10, access point 15 preferably 
comprises software which provides a user interface (for 
example, a graphical user interface) and is capable of 
executing the appropriate SCOS commands in accordance 
with the particular transaction being effected. For example, 
consider the case where a cardholder wishes to add a 
preference in car preferences EF 810 within rental car 
application 414 (shown in FIG. 8). In this instance, a 
cardholder would locate a convenient access point 15 (for 
example, a stand-alone kiosk in a mall) and insert card 100 
in a provided card reader in order to initiate a transaction. 
After suitable handshaking between card 100 and the card 
reader has taken place, and after the cardholder has been 
properly authenticated (i.e., the correct access conditions for 
updating car preferences EF 810 have been fulfilled), the 
application program at access point 15 queries the user with 
a choice of preference codes (for example, those listed in 
Table 39 above). The user then indicates a choice — through 
textual or graphical means, and the appropriate value is sent 
to card 100 by the application program as part of a command 
string. This value may then be sent to the appropriate 
partnering organization 12 (i.e., a rental car partner) and 
issuer 10 over network 19 to be stored in their respective 
databases 13 and 11. Alternatively, this data may be sent 
later as part of a card/database synchronization procedure, 
e.g., when the original transaction proceeds off-line. 

Consider, as another example, the typical hotel transac- 
tion. As detailed above, the cardholder inserts card 100 into 
a card reader deployed at a suitable access point 15. After 
appropriate initialization procedures take place, the card- 
holder is presented, through the use of a graphical user 
interface, the option to make a hotel reservation. Upon 



07/01/2004, EAST Version: 1.4.1 



6,101,477 

27 28 

choosing this option, the software may interrogate the hotel While the example transactions set forth above are 

preferences field in preferred programs EF 524 in cardholder described in general terms, the particular nature of data flow 

ID application 406 and display these hotels first within the to and from the appropriate memory locations within the 

list of possible choices. card will be apparent to those skilled in the art. 

After the cardholder selects a specific hotel property, the 5 Moreover, although the inventions set forth herein have 

software contacts the appropriate partner 12 over network 19 been described in conjunction with the appended drawing 

and requests a hotel room for a particular set of dates. This figures, those skilled in the art will appreciate that the scope 

step might involve an interrogation of the various files of the invention is not so limited. For example, although the 

within hotel system application 412 to which the particular preferred embodiment of the invention is discussed in the 

hotel has access (i.e., a hotel chain DF 902 or property DF 10 contcxt of a standard > credit card-sized smartcard with 

903), or this step may be deferred until check-in (as exter °f ****** ^ be W^ciated that virtually any 

described below) portable memory device suitably configured may be utilized 

Once a reservation has been made, the associated confir- to ? r * ctice this invention > for example, contactless cards, 

mation number supplied by the hotel is downloaded into the °P tIcal cards ' mmicards, "super-smart" cards, and the like, 

confirmation number field in reservation EF 918 along with 15 H ™*> vanous modifications m the design and arrangement 

the date and the property code of the hotel This step might of ^ e components and steps discussed herein may be made 

require the cardholder to transmit appropriate credit card wlt ^ out de P a ^ng from the scope of the invention as set forth 

information, which is suitably retrieved from payl EF 604. m ™ upended claims. 

Upon arrival at the hotel, the cardholder may use smart- y™ 1 15 claimed is: 
card 100 to access a kiosk or other convenient access point 20 L A smartcard apparatus of the type configured to corn- 
provided for check-in. Thus, check-in may take place unas- tunicate with an external device to perform a transaction, 
sisted by hotel personnel, or may involve a more traditional said smartcard apparatus comprising: 
person-to-person interaction where card 100 is used prima- a smartc ard body; 

rily to streamline the check-in process initiated by personnel aQ integrated circuit device disposed within said smart- 

at the front desk. 25 card body and configured to communicate with said 

At check-in, the confirmation number information is external device, said integrated circuit device compris- 

retrieved from reservation EF 918., and a particular room is m g a common application and a second application, 

assigned (if not assigned previously). This step will typically sa * d second application being configured to store 

involve retrieving, from the appropriate preference file (i.e., travel-related information associated with a cardholder; 

preferences EF 904 or 912), a list of preferences regarding 30 communicating means for providing data communication 

bed size, room type, and the like. This list may be matched between said integrated circuit device and said external 

against the hotel's database of available rooms, thereby device; and 

helping to streamline the room assignment process, said second application comprising a common file struc- 

Once a room is assigned, a digital key corresponding to ture and a partner file structure, wherein said partner 

the assigned room (e.g., a numeric value or alphanumeric 35 file structure provides write access to a field within said 

string) may be stored in key-of-the-room EF 910. Card partner file structure for a first partnering organization 

readers are then employed as part of the door lock apparatus and denies write access to said field for a second 

for each room, which are configured to open only upon partnering organiztion, and said common file structure 

receiving the correct key. provides write access for both said first and second 

At check-out time, payment may take place using pay- 40 partners to at least one filed in said common file 

ment card information stored in payment card EF 510 and structure. 

payl EF 604. Again, a suitable smartcard reader (i.e., ao 2. The smartcard apparatus of claim 1, wherein said 

access point 15), may be provided in any location conve- communication means comprises a plurality of external 

nient for check out, e.g., the hotel lobby or within the contacts disposed on a surface of said smartcard body, 

individual hotel rooms themselves. The cardholder may then 45 3. The smartcard apparatus of claim 1, wherein said 

acquire frequent stayer points, which would involve updat- second application comprises a payment system application, 

ing one of the stayer ID EFs 906 (or 936), During the course 4. The smartcard apparatus of claim 3, wherein said 

of his stay at the hotel, the cardholder may have incurred any payment system application is configured to store an account 

number of expenses related to room-service, on-site dining, number and an expiry date associated with a payment 

film viewing, and the like. These expenses, or a subset 50 account. 

thereof, may be conveniently downloaded into expenses EF 5. The smartcard apparatus of claim 1, wherein said 

916 for later retrieval, printout, or archiving. second application comprises an airline application. 

Use of card 100 in a rental car context would necessarily 6. The smartcard apparatus of claim 5, wherein said 

involve many of the same steps described above. The task of airline application is configured to store an electronic ticket, 

assigning a car would involve retrieving car preferences 55 7. The smartcard apparatus of claim 1, wherein said 

stored within preferences EF 805 and comparing them to a second application comprises a hotel application, 

database of available automobiles. Upon returning the 8. The smartcard apparatus of claim 7, wherein said hotel 

automobile, the cardholder might then be awarded frequent application is configured to store data associated with a hotel 

rental points (through update of frequent renter EF 807), and reservation. 

an expense record might be stored within expenses EF 811. 60 9. The smartcard apparatus of claim 1, wherein said 

In the airline context, card 100 could be used to make second application comprises a rental car application, 

reservations, record preferences, and provide a payment 10. The smartcard apparatus of claim 9, wherein said 

means as described above. In addition, electronic tickets rental car application is configured to store data associated 

may be downloaded (EF IET 710), and boarding information with a car preference. 

may be supplied via boarding EF 712. Frequent flyer EF 708 65 U. The smartcard apparatus of claim 1, wherein said 

may then be used to update the cardholder's frequent flyer common application comprises an application configured to 

miles. store indicia of said cardholder's identity. 
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12. The smartcard apparatus of claim 11, wherein said 
indicia of said cardholder's identity includes a name and an 
address. 

13. The smartcard apparatus of claim 1, wherein said 
common application provides general read access. 5 

14. A distributed transaction comprising: 

a network for transmitting transaction information: 
a partnering organization having an associated partnering 
organization server,said partnering organization server 
being configured to send and receive said transaction 10 
information over said network; 
a smartcard access point, said smartcard access point 
being configured to interface with a smartcard and to 
accept user input, wherein said access point is further 15 
configured to send and receive said transaction infor- 
mation over said network in response to said user input, 
said smartcard comprising; 
a smartcard body; 

an integrated circuit device disposed within said smart- 
card body and configured to communicate with said 



30 

smartcard access point, said integrated circuit device 
comprising a common application and a second 
application, said second application being config- 
ured to store travel-related information associated 
with a cardholder; 

said second application comprising a common filed 
structure and a partner file structure, wherein said 
partner file structure provides write access to a field 
within said partner file structure for a first partnering 
organization and denies write access to said field for 
a second partnering organization, and said common 
file structure provides write access for both said first 
and second partners to at least one field in said 
common file structure; and 

communication means for providing data communica- 
tion between said integrated circuit device and said 
smartcard access point. 

***** 
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